1. Field of the Invention
Embodiments of the present invention relate to the field of data storage systems using filesystem services, e.g., with a computer system. More particularly, embodiments of the present invention relate generally to the remounting of a root filesystem, without interrupting filesystem access service, from one device configuration to another in a computer system having mirrored volume disk storage.
2. Related Art
Secondary data storage is an integral part of large data processing systems. A typical data storage system in the past utilized a single, expansive magnetic disk for storing large amounts of data. For single disk memory storage systems, the speed of data transfer to and from the single, large disk is much slower than the processing speed of the Central Processing Unit (CPU) and acts as a data processing bottleneck. In addition, backup capability is needed for improved reliability and serviceability (RAS). In response to these needs, mirrored, redundant arrays of independent disks (RAIDs) have evolved from the single disk storage systems in order to match the speed of secondary storage access with the increasingly faster processing speeds of the CPU and improved RAS. To increase system throughput, the RAID architecture of secondary storage allows for the concurrent access of data from multiple disk drives.
Whether a system has standard single data storage devices or a RAID system of mirrored devices, there will inevitably come a time when a device will be swapped out due to failure, upgrade, etc. To swap out a device that is tied to a filesystem and mount a new one requires that the filesystem be unmounted from the first device and then mounted on the second. This necessitates the termination and restart of the filesystem services. In the case of the root filesystem, this necessitates rebooting the system. In order to reboot, the input/output (I/O) path from the device containing the root filesystem to the drivers for the new device needs to be known. In the case of booting off a mirrored volume device, this information is supplied to the booting firmware by a device that manages the storage devices, known as a Volume Manager. The Volume Manager needs to be initialized as part of the boot process.
Traditionally, the I/O path information has been supplied from the Volume Manager via a forceload list that is maintained by a system administrator who has the responsibility of maintaining the storage devices. As the complexity of the storage systems has increased, a method has recently become available that allows the Volume Manager to find the drive automatically, independent of the actual path, thus reducing the burden borne by the system administrator. One result of this change is that the path to each of the drivers is no longer a necessarily known quantity. As long as the Volume Manager is running and has I/O available it can dynamically locate the drivers. Therefore, the lack of a defined path would be of no concern. However, this greatly complicates the boot process.
The boot process involves starting with a firmware program such as, in the case of a SUN SPARC platform, for example, an open boot prom (OBP). The OBP firmware takes control Of whatever devices to which it has access by using preloaded drivers from firmware. The firmware programs on the OBP are not the same as the software programs that control the hardware when the operating system (e.g., SUN Solaris) is running. Therefore, the OBP and the operating system cannot both be running and controlling the same hardware, as there could be a conflict in instructions that would confuse the hardware. Thus, the OBP must handoff the hardware controls to the operating system kernel without an overlap. One of the main functions of the OBP firmware is to load and initialize the software that the kernel will need to access the storage system, e.g., create a filesystem.
One way to handle this handoff is shown as process 100a of Prior Art FIG. 1A. As shown in step 110, the firmware follows a predetermined forceload list and preloads all the driver modules from disk into memory for the devices that are needed in order to access the root filesystem. These drivers are the ones needed to establish the Volume Manager, in the case of a mirrored system. Then, as shown in step 120, access to I/O is turned off, known as “lights out,” at which point the OBP starts running the operating system (OS), but using hardware access via the preloaded driver modules from memory. During this “lights out” period, the root filesystem and the device on which it is mounted (root device) are established by initializing the just loaded drivers, devices, etc. Once the root filesystem is mounted on the root device, the kernel is started and the entire volume of mirrored devices must be established. In the instance of mirrored volumes, the root device is the Volume Manager. Once the rhirrored volume is established, I/O can be regained (“lights on”) as exemplified by step 130.
FIG. 1B is a block diagram showing a mirrored volume in a configuration that may exist following the boot process at the time of “lights on”. In this example Filesystem 140 interfaces with the Volume Manager 145 which interfaces with storage devices 150, 155, 160 and 165.
If, in order to initialize, the OS needed to bring something in from a disk during “lights out”, the OBP must have been provided a path to the disk. Therefore, if any of the driver components that are needed to mount the Volume Manager 145 are missing, the kernel will fail to start after lights out. Some of the driver modules needed by the OBP, for example in the case of RAID storage systems, are obtained from the Volume Manager which builds the forceload list for the OBP. In the instance where the system is running software in which the Volume Manager finds the drives independent of the actual path, it may not be able to supply the necessary information for the OBP to locate all necessary hardware. In the instance where the system administrator supplies the driver paths, there is always a possibility that there has been an error or omission in the update process.
As upgraded and additional software versions become available and as the mirrored systems become more complex, the burden on the Volume Manager to provide an accurate forceload list becomes great. It would be desirable to reduce this burden on the Volume Manager.